As a result of a question about a proposed pattern (SurrogateCustomer), Martine raised the following issues about context. Each pattern should be audited to ensure that these issues are adequately covered (or appropriately ignored) in the context or forces of the pattern:
Technical difficulty (easy or hard)
People difficulty (these two give us a 2x2 matrix...)
Technical difficulties include:
Innovations and how they are used.
Number of people involved
Size of the project (independent of number of people)
Schedule
Financing
Risks in the event of failure
New project or legacy project
People difficulties
Allies
Enemies
Individual personalities; team chemistry
Coprporate and surrounding organization culture (ISO, etc.)
I added some to Martine's list; add or remove as you see fit. So we want to look at each pattern, and make sure that the pattern covers each of the above. In many cases it may not matter, but we want to make sure we have at least thought about it. -- Neil Remember that the context is what glues patterns together in the pattern language. I'm concerned about the context surrounding the entire language and would prefer that we think about 1) the contexts for the entire language, and 2) the forces germane to each pattern. In short, I think we should redress this concern first by grappling more with the forces; a contextual precondition is a band-aid. -- Cope Ok, that said, I still think we need to examine each pattern to make sure we haven't missed things in the forces. I suggest we try doing in on a handful of patterns to see if the idea (of auditing them) hangs together. -- Neil
Context Audit
As a result of a question about a proposed pattern (SurrogateCustomer), Martine raised the following issues about context. Each pattern should be audited to ensure that these issues are adequately covered (or appropriately ignored) in the context or forces of the pattern:
- Technical difficulty (easy or hard)
- People difficulty (these two give us a 2x2 matrix...)
Technical difficulties include:- Innovations and how they are used.
- Number of people involved
- Size of the project (independent of number of people)
- Schedule
- Financing
- Risks in the event of failure
- New project or legacy project
People difficulties- Allies
- Enemies
- Individual personalities; team chemistry
- Coprporate and surrounding organization culture (ISO, etc.)
I added some to Martine's list; add or remove as you see fit.So we want to look at each pattern, and make sure that the pattern covers each of the above. In many cases it may not matter, but we want to make sure we have at least thought about it.
-- Neil
Remember that the context is what glues patterns together in the pattern language. I'm concerned about the context surrounding the entire language and would prefer that we think about 1) the contexts for the entire language, and 2) the forces germane to each pattern. In short, I think we should redress this concern first by grappling more with the forces; a contextual precondition is a band-aid.
-- Cope
Ok, that said, I still think we need to examine each pattern to make sure we haven't missed things in the forces. I suggest we try doing in on a handful of patterns to see if the idea (of auditing them) hangs together.
-- Neil